home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / applications / 4852 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.7 KB

  1. Path: news.muc.de!hwg!heinz
  2. Subject: Re: Final Writer 5 Features
  3. Newsgroups: comp.sys.amiga.applications
  4. References: <woody-0904961439260001@woody.softwood.com> <xbRj0MD30Aaez3@galdor.papa.north.de> <4kof6b$1b5@news.tiac.net>
  5. Organization: Private
  6. Distribution: world
  7. X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
  8. From: heinz@hwg.muc.de (Heinz Wrobel)
  9. Message-ID: <heinz.17uj@hwg.muc.de>
  10. Date: Fri, 19 Apr 96 15:35:08 GMT
  11.  
  12. David Meyer (dmeyer@tiac.net) wrote:
  13. >part of a large document. This is somewhat true of any editor with even 
  14. >the most minimal page formating features, like word wrap or page break, 
  15. >but the WYSIWYG programs suffer more and those with a multitude of 
  16.  
  17. This is not really fully correct. A WP/editor does not have to be
  18. noticably slower when editing the start of a larger text.
  19. Considering a reasonable WP text memory implementation, a WP has to
  20. relayout more than the current paragraph only when the line count
  21. changes. Let's assume that we add or delete a line in the beginning
  22. of a document with n pages. This means that we have to check at
  23. most n+1 paragraphs for a relayout and even there we don't actually
  24. have to fully relayout the current text in the current paragraph.
  25. The other n paragraphs only need to be updated in terms of the page
  26. break location. All the paragraphs that don't need to be checked
  27. for a relayout at a page break only need to be updated via a Y
  28. offset addition which needs to be updated itself at most once per
  29. page. Assuming that we use a linked list of paragraphs (of course
  30. we do, don't we?), we'd need an estimated 2*(n+1) list insertions
  31. deletions and n+1 field updates for a reasonable implementation. No
  32. lengthy text fit or length calculations involved at all as the
  33. line representation of a vertically moved paragraph doesn't change
  34. at all. For anchored or text flow graphics, additional calculations
  35. are obviously needed. But even there it can usually be reduced to
  36. placement checks and Y coordinate or list position updates. No need
  37. to move large memory blocks. And if a forced page break is inserted
  38. after a paragraph on e.g. page n/2, it might very well be that we
  39. can cut short all the calculations at page n/2 beause the following
  40. pages won't change. For page cross references, we can avoid an n!
  41. like update algorithm by remembering them in a list and do one
  42. final linear update. For typical documents, I feel that 1ms per
  43. paragraph update (not relayout) on an A3k is plenty. That is only a
  44. "top of my head worst case" feeling, so you'd notice a bad slowdown
  45. per line insertion only for fairly huge sections. It is probably
  46. easy to cut down the typical check to a lot less than 1ms per page.
  47.  
  48. Note that display time is needed only once, and even there it is a
  49. partial screen scroll, and an update of the scrolled areas. Display
  50. time is not an issue here.
  51.  
  52. So if a WP gets slow on large amounts of text, the implementation
  53. for internal text memory handling needs to improved. I know that
  54. FW4 currently has this problem and I hope that something has been
  55. done about it for FW5. I do not say "it so easy to fix this or
  56. that" because I know it hardly ever isn't. I hope for the best,
  57. though, because I'd like to use FW for larger documents, too. I
  58. don't like to start a new section every 10 pages. :^)
  59.  
  60. Two other annoying things that I hope to see fixed is that marking
  61. text with the keyboard is wasting my time with really excessive
  62. block marker redraws and that I can't configure the keyboard
  63. mapping. I'd like to change at least the qualifiers for
  64. cursor key movement.
  65.  
  66. >FW5 in our hands first before we start pleading for more. Woody & crew 
  67. >were pretty good about the FW5 lists posted here.
  68.  
  69. Yes. I'll update as soon as possible, too. I like FW.
  70.  
  71. -- 
  72. Heinz Wrobel        Private Mail:   heinz@hwg.muc.de
  73. My private FAX: +49 89 850 51 25, I prefer email
  74.